In the field of telecommunications, it is common for different classes of network traffic to exist. Network traffic is classified by a variety of means. A common example is traffic belonging to a particular subscriber to the network. Subscribers are grouped into different classifications for a variety of reasons, including, but not limited to, the level of service purchased (minutes, bandwidth, features etc), their location/geography, the type of handset/user equipment (UE) utilized, the business or enterprise to which they belong, or the network segment/server or point-of-interconnect to which they are assigned/attached.
Different nodes in the network may have lesser or greater (or even completely different) knowledge about these classifications. Generally, it is incumbent upon the network provider to manually manage the subscriber classification definitions on each node to ensure that a subscriber's traffic flow receives common treatment regardless of which node it traverses. For example, network operators may be required to pre-configure (static) data to define these groups and allocate subscribers to these groups, thus incurring an Operations, Administration, and Management (OA&M) cost to set up a subscriber and again each time a service or subscriber changes.
In addition, classifications/grouping constructs within a network node's data model typically have a fixed meaning (as determined by the equipment vendor's software), and may not match the network operator's view of how it classifies subscribers or defines services. As a result, equipment vendors either develop custom software for network operators, or the network operator compromises its desired classification schema (in terms of costs, efficiencies, or quality of service delivered).
Also, classification/grouping data models are frequently flat or hierarchical, which can make it difficult to have subscribers belong to multiple classifications simultaneously. In a network that includes software from multiple vendors (e.g., a mixed vendor network), data models between nodes are frequently different. Thus, a network operator may have difficulty defining a consistent classification and service view for a given subscriber or service across all the equipment through which the subscriber's service is delivered.
Another difficulty with traffic classification arises when more than one network node (such as a border/edge device and a centralized session device) each have different information about the traffic flow available based on the specific scope of signaling or configuration to which the network nodes are exposed. In some cases, the decision to apply a service can be reasonably made based on the information available at just one of the nodes. However, situations can occur where information available individually to each node must be combined in order to make the most optimal service decision for the traffic flow and/or subscriber.
A common approach to these difficulties is to continuously add specific data items into the signaling protocols connecting the network nodes such that sufficient information is available to whichever node needs to make a decision for that specific subscriber or service. However, this approach can require frequent incremental changes to each node involved such that services can be slow and/or costly to introduce to a network. This approach can also result in traffic flow classification and service application decisions based on incomplete information, simply because that is what is available, which leads to inefficiencies, inaccuracies or undesirable user experiences.
FIG. 1 is a block diagram of a prior art system 100 for receiving traffic flows at a session border controller 110 (“SBC”) from user equipment 105a-c (“UE”) for transmission to an application server 120. Generally, the application server 120 is unaware of much of the physical topology of the network(s) the UEs 105a-c are using. For example, the topology may be masked from the application server 120 due to a network security implementation. Also, the application server 120 may not be aware of information that the SBC 110 is aware of (e.g., the actual transport protocol the UEs 105a-c use, the original application protocol the UEs 105a-c use to connect to the SBC 110). Conversely, the application server 120 may be aware of information that the SBC 110 is not aware of. For example, the operator of the network can provision a richer data model at the application server 120 regarding the details of the subscriber and the services they utilize, than can be provisioned at the SBC 110.
The physical separation of roles between the SBC 110 and the application server 120 has a number of benefits (e.g., security, scalability, processing efficiency), but the physical separation can make it harder to determine the optimum service match for traffic flows as a result of the different information available to the SBC 110 and the application server 120. For example, a network operator may intend to record all calls received from a particular access network segment, on which one of the UEs (e.g., User Equipment A 105a) is located. However, the application server 120 is the node which is connected to the recording platform, yet the SBC 110 is the node that knows the specific access network segment on which the UE 105a is located and from which the traffic flow originated.
Therefore, a need exists for a flexible and dynamic technique for classifying traffic flows into groups and applying service to the traffic flows based on the classification groups across multiple nodes in a network.